Method, network device and system for providing profile data applicable to hypertext transfer protocol (http)

ABSTRACT

The present invention is based on a concept to provide session and profile management for network communication, especially over hypertext transfer protocol (HTTP), employing available communication methods. Session and profile management is available and standardized for mobile communication by the means of the wireless session protocol (WSP) employable for wireless application protocol (WAP) communication. This wireless session protocol (WSP) is limited to mobile communication. The analog communication standard hypertext transfer protocol (HTTP) available and standardized for wireline communication does not offer a session and profile management. The present invention offers a method to establish an analog session and profile management by the means of cookies or modified uniform resource locators (URL) even over the hypertext transfer protocol (HTTP) without requiring substantial changes to the hypertext transfer protocol (HTTP) standard.

CROSS-REFERENCE TO RELATED APPLICATION

This application is the U.S. National Stage of International ApplicationNumber PCT/IB02/00628 filed Mar. 4, 2002.

BACKGROUND OF THE INVENTION

The present invention relates to a method, a network device and a systemfor providing profile data to a requesting device. In particular, thepresent invention relates to a method, a network device and a system forproviding user agent profile (UAProf) information on the basis ofcookies or modified uniform resource locators (URL) for coding andcommunicating information relating to a cached user agent profile(UAProf).

As WEB- and WAP-enabled devices come of age, an assumption of devicehomogeneity within the respective group of WEB- and WAP-enabled devicesis no longer universally valid. The Internet world is rapidly growing,beyond the personal computer (PC) world, into the consumer home market.A variety of Internet information appliances are already put into themarket, and seem to spread very far. Examples of Internet informationappliances are Internet-TVs, set-top-boxes, home word-processors,personal digital assistants (PDA), smart phones, and car navigationsystems. In particular, mobile devices can be expected to have anever-divergent range of input and output capabilities, such as number ofdisplayed colors, and different form-factors of keyboards, networkconnectivity, levels of scripting language support, and the like.Moreover, users may have content presentation preferences that alsocannot be transferred to the server for consideration. As a result ofthis device heterogeneity and of the limited ability of users to conveytheir content presentation preferences to the server, clients mayreceive content that they cannot store, that they cannot display, thatviolates the desires of the user, or that takes too long to convey overthe network to the client device.

Work is ongoing in the World-Wide-Web Consortium (W3C) to definemechanisms for describing and transmitting information about thecapabilities of Web clients and the display preferences of Web users.The composite capabilities/preferences profile (CC/PP) specificationdefines a high-level structured framework for describing thisinformation; the composite capabilities/preferences profile (CC/PP) iscoded within the header of the HTTP/1.0 and HTTP/1.1 header with acompatible straightforward extension. CC/PP profiles are structured intonamed “components,” each containing a collection of attribute-valuepairs, or properties. The mechanism by which the profile is transportedbetween the mobile terminal, WEB proxies and servers is defined in thisspecification.

The user agent profile (UAProf) specification extends WAP 1.x and WAP2.0 to enable the end-to-end flow of a user agent profile (UAProf), alsoreferred to as capability and preference information (CPI), between theWAP client, the intermediate network points (such as WAP gateways andWEB proxies), and the origin server. It seeks to inter-operateseamlessly with the emerging standards for compositecapability/preference profile (CC/PP) distribution over the Internet. Ituses the CC/PP model to define a robust, extensible framework fordescribing and transmitting CPI about the client, user, and network thatwill be processing the content contained in a WSP/HTTP response. Thespecification defines a set of components and attributes thatWAP-enabled devices may convey within the CPI. This CPI may include, butis not limited to, hardware characteristics (screen size, colorcapabilities, image capabilities, manufacturer, etc.), softwarecharacteristics (operating system vendor and version, list of audio andvideo encoders, etc.), application/user preferences (browsermanufacturer and version, markup languages and versions supported,scripting languages supported, etc.), WAP characteristics (WML scriptlibraries, WAP version, WML deck size, etc.), and networkcharacteristics (bearer characteristics such as latency and reliability,etc.). This specification seeks to minimize wireless bandwidthconsumption by using a binary encoding for the CPI and by supportingefficient transmission and caching over WSP in a manner that allows easyinteroperability with HTTP.

As a request travels over the network from the client device to theorigin server, each network element may optionally add additionalprofile information to the transmitted CPI. These additions may provideinformation available solely to that particular network element.Alternatively, this information may override the capabilities exposed bythe client, particularly in cases where that network element is capableof performing in-band content transformations to meet the capabilityrequirements of the requesting client device. Origin servers, gateways,and proxies can use the CPI to ensure that the user receives contentthat is particularly tailored for the environment in which it will bepresented. Moreover, this specification permits the origin server toselect and deliver services that are appropriate to the capabilities ofthe requesting client.

The above presented drafts and specifications referring to compositecapabilities/preferences profile (CC/PP) and user agent profile(UAProf), respectively, exhibits a number of disadvantages concerningthe involved terminal devices, intermediate network devices, such asproxies and gateways, and servers.

The wireless session protocol (WSP) allows WAP-enabled clients toestablish a session mechanism for managing the communication of the useragent profile (UAProf). Upon initiating a WSP session with e.g. a WAPgateway, the UAProf-aware client transfers its profile informationwithin a WSP connect request. Upon receiving the profile information, aWAP-gateway that is aware of the UAProf capability caches the CPI, whichwill be effective for the lifetime of the session. The client may updatethe UAProf or resume or suspend the session on corresponding requests.To request content of a server during a WSP session, the client issues astandard WSP request to the WAP-gateway. The WAP-gateway is responsiblefor forwarding this WSP request to the designated origin server(typically via HTTP). In forwarding the request, the WAP-gateway mustinclude the cached CPI associated the corresponding WSP session. Theorigin server receives the HTTP request, resolves the CPI, and generatesa response along with a profile-warning header indicating whether theCPI was taken into account as the content was generated. The WAP gatewayforwards the content to the client device over WSP, encoding theprofile-warning header for efficient transmission over the wirelessnetwork.

Whereas the CPI has to be included within each HTTP request in order toobtain a CPI-adapted response, the session mechanism of the WSP providescached UAProf or CPI, respectively, demanding a communication thereofonly in case of the establishing of the session and/or in cases ofrequired updates. In contrast to the concept of UAProf communicated viaWSP, a CPI extended HTTP based network device connection wastesbandwidth. Moreover, the wasting of bandwidth concerns even wirelesscommunication since UAProf capable clients employ wireless communicationbased on wireless profiled HTTP (W-HTTP) which is smoothly adapted tothe requirements of the wireless communication. UAProf capable clientshave to transmit CPI data in each W-HTTP request that is madecorresponding to the mechanism of CPI handling described above inconnection with HTTP server requests.

Further, included CPI in HTTP requests has to be processed by eachgateway, proxy and server effected by the included CPI data. Theprocessing of the CPI or UAProf data, respectively, includes, but is notlimited to, parsing of the corresponding HTTP fields, validating thesequencing and MD5 digest, resolving the complete profile according tothe rules stipulated in the CPI or UAProf standard, respectively, andupdating the resulting profile. This profile processing and resolutionis a complex and heavy operation, which should be avoided if possible. Asession management provides the advantage that the processing of the CPIor UAProf data, respectively, has only to be performed in case of achanging in the CPI or UAProf data, respectively, which occurs at theinitiating of the session and in connection with an update of the CPI orUAProf data, respectively.

A UAProf-aware client may introduce differences of its standard profile.Employing HTTP based communication, the introduced differences must becommunicated in addition to the standard profile included in each HTTPrequest. Therefore, the client has to store information about theintroduced differences as long as they are relevant. A sessionmanagement relieves the client of storing this kind of information andthis is of particular interest in combination with mobile clients oflimited memory capacity.

Even the current realization of the WSP concept exhibits a number ofdisadvantages concerning the usability and the ability of implementing.The session information essential for providing a session managementaccording to the description above is available only at the WSP protocollevel, which is just one level above the transport layer. The sessionand UAProf support relate to the application level. The access toinformation of the WSP protocol level from the application layer is onlypossible when all components of the session management are implementedin one dedicated processing device. The necessary tight coupling betweenthe required WSP and UAProf implementation makes it difficult to providemodular, flexible and efficient systems. Further, even when the WSPsession concept is implemented, e.g. within a WAP-gateway, thecommunication to serving network devices requested by a client ispreferably communicated over a session-less HTTP communication leg. Thecorresponding network devices are subject to all of the aforementioneddisadvantages.

BRIEF SUMMARY OF THE INVENTION

The object of the present invention is to provide cached profile datafor the generation of request responses, preferably of WEB/WAP servers.A session management module may manage the profile data. The presentedsolution is applicable not only to hypertext transfer protocol (HTTP)and its wireless variant W-HTTP, but also to the wireless applicationprotocol (WAP) establishing a session mechanism analog to the wirelesssession protocol (WSP). The session management according to the presentinvention further provides an applicable end-to-end session managementmechanism, offering the advantages to all participating devices of theend-to-end chain. Correspondingly, a method, a device and a system forproviding profile data is provided.

The object of the present invention corresponding to the providedmethod, device and system for providing profile data is solved accordingto the description that follows below.

According to an embodiment of the present invention, a method forproviding profile data is provided. Preferably, the profile data may beCPI or UAProf information. The profile data are cached in order to beretrieved. These profile data are uniquely assigned to a requestingdevice, such as a client device. In a first operational step a requestand an associated cookie are received. The request may compriseinstructions for a serving device in order to initiate the generation ofa corresponding response transmitted back to the requesting clientcomprising data in accordance with these instructions. The cookiecomprises information that is used for retrieving profile data.Preferably, the comprised information represents a unique indicator orpointer to the profile data, respectively, which are advantageouslyassigned uniquely to the requesting device. In a following step, theprofile data are retrieved correspondingly e.g. from a dedicated profiledata cache. In a further step, a response in accordance with the requestis generated. The generation of the response may take account of theprofile data, especially the UAProf, in order to meet the needs andrequirements of the requesting device and the request generatingapplication regarding the UAProf information. A response cookie mayadditionally be generated comprising signaling information according tothe generation of the response and update information according to theprofile data caching. In a final step the response and, if generated,the cookie, are transmitted back to the requesting device.

According to an embodiment of the present invention, a method forproviding profile data is provided. Preferably, the profile data may beCPI or UAProf information. The profile data are cached in order to beretrieved. These profile data are uniquely assigned to a requestingdevice, such as a client device.

In a first operational step a request from a requesting device isreceived. The request may comprise instructions for a serving device inorder to initiate the generation of a response transmitted back to therequesting client comprising data in accordance with these instructions.Each request contains an address coding the requested data. Incombination with WEB/WAP server a uniform resource locator (URL) is usedfor coding the address. Herein the request contains a modified uniformresource (URL) locator addressing a certain source (a server and contentof this server) and comprising information for retrieving profile data.Preferably, the comprised information represents a unique indicator orpointer to the profile data, respectively, which are advantageouslyassigned uniquely to the requesting device. The modified uniformresource locator (URL) may be composed of the original uniform resourcelocator (URL) and a sequence coding the information to be retrievedappended to the original unmodified uniform resource locator (URL). Boththe original uniform resource locator (URL) and the sequence coding theinformation may be separated easily. The coding may not interfere withthe original purpose of the uniform resource locator (URL). In afollowing step, the profile data are retrieved correspondingly e.g. froma cache. In a further step, a response in accordance with the request isgenerated. The generation of the response may take account of theprofile data, especially the UAProf, in order to meet the needs andrequirements of the requesting device and the request generatingapplication regarding the UAProf information. The resulting response maycontain a plurality of uniform resource locators (URLs) referring tofurther content of a server, usually designated as links or hyperlinks.These uniform resource locators (URLs) are modified by appendinginformation for retrieving the aforementioned cached profile data. Theresulting modified uniform resource locators (URLs) are of the same typedescribed above in connection with the uniform resource locator (URL)contained in the request. In a final step the response is transmittedback to the requesting device. A selection of one of the modifieduniform resource locators (URL) comprised in the response may lead to arequest in the same manner as described in the current embodiment.

According to an embodiment of the present invention, the caching of theprofile data to be provided for retrieving may be based on a sessionconcept, which means that the profile data are available to be retrievedduring a certain period of time. This period of time may be termed asession. The profile data session may be established by an initialprocedure leading to the caching of profile data and the generation ofinformation necessary for the retrieval thereof, and the uniqueassignment to a requesting device. An initial request may establish theprofile data for retrieving. Therefore, the initial request has tocomprise the profile data to be cached in order to be retrieved by anysubsequent request comprising information for retrieving. The caching ofthe profile data or the profile data session may be terminated byremoving the profile data from the cache, respectively. The removing maybe operated at the end of a period of time passed by, for examplerelating to the last request.

The session concept may require additional information to becommunicated from the requesting client. This additional information maybe a session identifier, preferably, a session-identifying sequence. Theadditional information may be comprised in the information forretrieving. According to an embodiment of the method of the presentinvention, the above described received cookie may comprise informationfor retrieving profile data relating to the requesting client and maycomprise information identifying the associated session relating to theprofile data and the requesting client. Analogously, according to anembodiment of the method of the present invention, the above describedmodified uniform resource locator (URL) may comprise information forretrieving profile data relating to the requesting client and maycomprise information identifying the associated session relating to theprofile data and the requesting client for example both appended to theoriginal uniform resource locator (URL).

According to an embodiment of the present invention, the step ofgenerating the response may further comprise a step of generating aserver response, transmitting the server response to a serving deviceand receiving a corresponding server response. The server request isbased on the instructions and information comprised by the clientresponse. Correspondingly, the server response is based on the serverrequest and hence is based on the original request received from therequesting device.

According to an embodiment of the present invention, the request of therequesting device may be a request addressed to a WEB/WAP-serverrequesting content of this WEB/WAP-server. Correspondingly, the responsegenerated in accordance with the request may be a WEB/WAP-serverresponse.

According to an embodiment of the present invention, the method forproviding profile data may be applicable to the hypertext transferprotocol, which is employed for coding the request and the response forcommunicating over a communication network. Additionally, the providingof profile data may be applicable to the wireless application protocol(WAP).

According to an embodiment of the present invention a software tool forproviding profile data is provided. The software tool comprises programportions for carrying out the operations of the aforementioned methodswhen the software tool is implemented in a computer program and/orexecuted.

According to a further embodiment of the present invention a computerprogram for providing profile data is provided, comprises program codesection for carrying out the above operations of the above methods forproviding profile data when said program is run on a computer or anetwork device.

According to a further embodiment of the present invention a computerprogram product for providing profile data is provided comprisingprogram code section stored on a computer readable medium. The computerprogram code sections are for carrying out the above mentioned methodfor providing profile data when said program product is run on acomputer or network device.

According to a further embodiment of the present invention a networkdevice for providing and managing profile data and session informationis provided. The network device comprises a communication interface, asession manager and a serving component. The communication interfaceprovides the ability to communicate to a requesting device by receivingand/or transmitting requests and responses, respectively. Additionally,cookies associated with these requests and responses are alsocommunicated. The session manager manages the profile data. Therefore, adedicated cache for caching profile data may be accessible by thesession manager. The session manager is enabled to retrieve the profiledata from this cache in accordance with information comprised in areceived cookie referring to profile data. For this, the session managermay decode received cookies which are associated to a request and whichcomprise information for retrieving profile data. The retrieved profiledata are supplied to the serving device. The serving device generates aresponse based on the received request. The generation of the responseis further based on the supplied profile data. The profile datacomprises CPI and UAProf information, respectively, representingabilities of the requesting device that may have to be taken intoconsideration in combination with the generation of the responses. Thenetwork device according to an embodiment of the invention is adapted tooperate the aforementioned methods for providing profile data inconnection with an associated cookie comprising information forretrieving the profile data.

According to a further embodiment of the present invention a networkdevice for providing profile data is provided. The network devicecomprises a communication interface, a session manager and a servingcomponent. The communication interface provides the ability tocommunicate to a requesting device by receiving and/or transmittingrequests and responses, respectively. A received request comprises amodified uniform resource locator (URL) including the original uniformresource locator (URL) and information for retrieving profile data. Thesession manager manages the profile data. Therefore, a dedicated cachefor caching profile data may be accessible by the session manager. Thesession manager retrieves these profile data by the referring andsession information and supplies the profile information to the servingcomponent. The session manager may decode modified uniform resourcelocator (URL) in order to obtain the information for retrieving. Theserving device generates responses based on the received requests. Thegeneration of the response is further based on the supplied profiledata. The profile data may comprise CPI and UAProf information,respectively, representing abilities of the requesting device that mayhave to be taken into consideration in combination with the generationof the responses. Further the serving component processes the originaluniform resource locators (URLs) included in the generated response. Theoriginal uniform resource locators (URLs) are modified by appendinginformation for retrieval of the profile data. The network deviceaccording to an embodiment of the invention is adapted to operate theaforementioned methods for providing profile data in connection with amodified uniform resource locator (URL) comprising information forretrieving the profile data.

According to a further embodiment of the present invention the servingcomponent of the network device may be able to generate a serverrequest. The communication interface may transmit this server request tothe server and may receive subsequently a server response based in theserver request. The generation of response for the requesting device maytake account of the response of the server.

According to a further embodiment of the present invention the networkdevice may be a server network device, Conveniently, network device maybe a proxy network device or a gateway network device.

According to a further embodiment of the present invention a system forproviding profile data is provided. The system comprises a requestingdevice and a network device. The network device is a network deviceaccording to an embodiment of the network device of the presentinvention; in particular, the network device is a server network device.Correspondingly, the network device may be able to operate according toan embodiment of the method of the present invention. The requestingdevice may be able to generate a request according to the requirementsand needs of an embodiment of the method of the present invention.

The system may allow operating the following operational steps. In afirst step, requesting device may generate a request and transmit therequest to the network device. The network device may receive therequest. The request comprises information for retrieving profile data.The information may be contained in a cookie associated with the requestand transmitted to the network device, and received thereby.Alternatively, the information may be comprised within a modifieduniform resource locator (URL) like that described above. Preferably,the profile data may be uniquely assigned to the requesting device andare cached by a cache associated to the network device. In a furtherstep, the profile data may be retrieved in accordance with theinformation contained in the cookie and may be supplied for generating aresponse. The response may be generated by the network device based onthe request and taking into account the profile data. The coding of theinformation for retrieving the response may be processed in case of arequest containing a modified uniform resource locator (URL). Modifieduniform resource locators (URLs) contained in the response may beprocessed by including information for retrieving according to anembodiment of the method of the present invention. Alternatively, aresponse cookie may be generated. In a final step the response and thecookie may be transmitted back to the requesting device and may bereceived by the requesting device.

According to a further embodiment of the present invention a system forproviding profile data is provided. The system comprises a requestingdevice, an intermediate network device and a server. The intermediatenetwork device is a network device according to an embodiment of thenetwork device of the present invention, in particular, the networkdevice is a proxy network device or a gateway network device. Further,the intermediate network device is able to operate according to anembodiment of the method of the present invention. The requesting deviceis able to generate a request according required by an embodiment of themethod of the present invention. The server is able to provide aresponse based on the request of the requesting device. The requestingdevice communicates with the server via the intermediate network device.

The system may allow operating the following operational steps. In afirst step, a requesting device may generate a request and transmit therequest to the network device. The network device may receive therequest. The request comprises information for retrieving profile data.The information may be contained in a cookie associated with the requestand transmitted to the network device, and received thereby.Alternatively, the information may be comprised within a modifieduniform resource locator (URL) like that described above. Preferably,the profile data may be uniquely assigned to the requesting device andare cached by a cache associated to the network device. In a furtherstep, the profile data may be retrieved in accordance with theinformation contained in the cookie and may be supplied for generating aresponse. The response may be generated by the network device based onthe request and taking account of the profile data. The generation ofthe response may involve generating of a server request, transmitting ofthe server request to the server and receiving of a server response inaccordance to the server request. Corresponding to the coding of theinformation for retrieving the response may be processed in case of arequest containing a modified uniform resource locator (URL). Aplurality of uniform resource locators (URLs) comprised by the responsemay be processed by including information for retrieving according to anembodiment of the method of the present invention for obtainingcorresponding modified uniform resource locators (URLs) for subsequentrequests. Alternatively, a response cookie may be generated. In a finalstep the response and the cookie may be transmitted back to therequesting device and may be received by the requesting device.

Embodiments of the present invention will be further illustrated andexplained to those of ordinary skill in the art after having read thefollowing detailed description of the embodiments which are exemplifiedin the various drawing figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 a shows a flow diagram illustrating a sequence of processingoperations with respect to the operation of a server and a gateway,respectively, according to an embodiment of the invention,

FIG. 1 b shows a flow diagram illustrating a sequence of processingoperations with respect to the operation of a server and a gateway,respectively, according to an embodiment of the invention,

FIG. 2 a shows a block diagram illustrating a system of a client and aserver according to an embodiment of the invention,

FIG. 2 b shows a block diagram illustrating a system of a client, agateway and a server according to an embodiment of the invention,

FIG. 3 a shows a flow diagram illustrating a timely sequence of theoperations with respect to FIG. 2 a and according to an embodiment ofthe invention,

FIG. 3 b shows a flow diagram illustrating a timely sequence of theoperations with respect to FIG. 2 b and according to an embodiment ofthe invention,

FIG. 4 a shows a flow diagram illustrating a sequence of processingoperations with respect to the operation of a server and a gateway,respectively, according to an embodiment of the invention,

FIG. 4 b shows a flow diagram illustrating a sequence of processingoperations with respect to the operation of a server and a gateway,respectively, according to an embodiment of the invention,

FIG. 5 a shows a block diagram illustrating a system of a client and aserver according to an embodiment of the invention,

FIG. 5 b shows a block diagram illustrating a system of a client, agateway and a server according to an embodiment of the invention,

DETAILED DESCRIPTION OF THE INVENTION

In the figures corresponding reference numerals denote correspondingfeatures.

FIG. 1 a shows a flow diagram illustrating a sequence of processingoperations with respect to the operation of a server and a gateway,respectively, according to an embodiment of the invention. The sequenceof processing operations illustrates the establishing of the profiledata and session managing in accordance with an initial client request.Due to the inter-action of processing devices within an end-to-endcommunication chain, the concept of the present invention will bedescribed with reference to a terminal client and a terminal server asalso to a terminal client and an intermediate network device, i.e. aninter-acting gateway or proxy.

Client—Server Communication:

The following operations are dedicated to and operated by a servercommunicating with a client, both supporting the profile and sessionmanagement according to an embodiment of the present invention.

In an operation S1.20, the initial request operation is started.

In an operation S1.21, a server receives an initial request. The initialrequest comprises, according to the description above, user agentprofile (UAProf) information. The server recognizes on the basis of thecomprised UAProf that a session has to be opened and the initial UAProfinformation has to be established.

In an operation S1.22, the initial UAProf information is cached. TheUAProf information may be optionally modified by the server withadditional server-related UAProf information, reflecting informationonly available to the server.

In an operation S1.23, referencing and session information is obtained.The referencing and session information comprises a code sequence bywhich the cached UAProf information is accessible and retrievable, i.e.this code sequence may be termed as a pointer pointing to the cachedUAProf information. Further, the referencing and session information mayadditionally code a unique session identification, such that the servermay identify a subsequent client request as belonging to thisestablished session.

In an operation S1.24, a response in accordance with the client requestis generated. For example, the client may request to access a certainWAP/WEB page provided by the server. Therefore, the request may comprisean identifier of this certain WAP/WEB page, usually a uniform resourcelocator (URL). The server may retrieve the indicated WAP/WEB page fromits storage area and generates a corresponding request response. Inorder to inform the client of the established session and to put theclient in the position to transmit a unique session identifyinginformation upon subsequent requests to the same server, a cookie isgenerated. The cookie may preferably comprise the referencing andsession information aforementioned with reference to operation S1.23.The coding of the aforementioned referencing and session information mayfurther be completed by adding a signaling sequence in order to indicatefor example that the caching operation has been performed, that theUAProf information has been taken into account during the generation ofthe request response or that the UAProf information has been rejected orthe serving device is not able to take account of the UAProf informationor parts thereof.

In an operation S1.25, the generated request response and the cookie aretransmitted to the client.

In an operation S1.26, the operational sequence in accordance with theinitial client request is finished.

Client—Gateway Communication:

The following operations are dedicated to and operated by anintermediate network device such as a gateway and a proxy, respectively,communicating with a client, both supporting the profile and sessionmanagement according to an embodiment of the present invention.Advantageously, the description of the Client—Gateway Communication maydistinguish between a server supporting the profile and sessionmanagement according to an embodiment of the present invention, and aconventional server that does not support sessions.

In both cases, the intermediate network device operates the operationsS1.20 to S1.23 in the same manner compared with the aforementionedoperations S1.20 to S1.23 referencing to the Client—ServerCommunication. The operation S1.22 may comprise a modifying operation inaccordance with the tasks of an intermediate negotiating network device,herein described with reference to an intermediate network device. TheUAProf information may be optionally modified by the intermediatenetwork device with additional server-related UAProf information,reflecting information only available by the intermediate networkdevice, e.g. to better meet the needs of the requesting client. Theoperation S1.24 comprises a plurality of additional operations referringto the server communication.

Profile and Session Managing Server:

In an operation S1.27, a server request is generated. The generation ofthe server request may entail a conversion of the client request. Theclient request may be based on another transfer protocol as the serverrequest. The information included in the client request may be takenover without modifying the content of the information. For example, aclient request is received based on WAP and has to be forwarded to anHTTP based server. Correspondingly, the intermediate network deviceconverts the client request. The comprised user agent profile (UAProf)information is maintained by the generating operation. In case of aprior modification of the UAProf described in operation S1.24, themodified user agent profile (UAProf) information may be included in thegenerated server request.

In an operation S1.28, the server request is transmitted to the server.

In an operation S1.29, a server request response is received. The serverhas preferably operated the operations S1.20 to S1.26 according to theaforementioned description referring to a server according to anembodiment of the present invention. Correspondingly, the server requestresponse comprises a server response cookie. This server response cookiecomprises referencing and session information of the UAProf caching andsession managing of the server, and correspondingly may comprise acorresponding signaling sequence as described above.

In an operation S1.24, the intermediate network device generates aclient request response based on the server response to the request. Thegeneration may entail a conversion operation, e.g. to convert the serverresponse information coded in a certain transfer protocol into atransfer protocol suitable for communication with the client. Thegenerating operation may additionally take into account the UAProfinformation according to the version cached by the intermediate networkdevice. For example, the cached UAProf information may be taken intoaccount in case that the generated response does not fulfil allrequirements of the client due to an incomplete considering of theUAProf information by the server, e.g. due to lacking servercapabilities. Referencing and session information of both theintermediate network device, and the server is available. Thereferencing and session information relating to the server may beadditionally cached by the intermediate network device to be retrievedalternatively to the UAProf of the client by the referencing and sessioninformation relating to the intermediate network device. Further, bothreferencing and session information may be coded in cookies and added tothe client request response, or may be coded in a single cookiecomprising the complete information, and added to the client requestresponse.

In an operation S1.25, the generated request response and the cookie aretransmitted to the client.

Non-Session Managing Server:

In an operation S1.27, a server request is generated. The generation ofthe server request is similar to the generating operation S1.27described above with reference to the profile and session managingserver.

In an operation S1.28, the server request is transmitted to the server.

In an operation S1.29, the intermediate network device receives thecorresponding server response to the request. According to thecapability of the server, the received server response may be based onthe transmitted UAProf comprised in the server request, or the servermay have not taken into account the provided UAProf.

In an operation S1.24, the generating operation may consideradditionally the UAProf information according to the version cached bythe intermediate network device. For example, the cached UAProfinformation may be taken into account in case that the generatedresponse does not fulfil all requirements of the client due to anincomplete taking account of the UAProf information by the server, e.g.due to lacking server capabilities. Particularly, the intermediatenetwork device may take the UAProf information during the generatingoperation into consideration in case of a server, which is not capableto take adequately the transmitted UAProf information into account.Further, the generating operation may code a cookie comprisingreferencing and session information according to the session managementof the intermediate network device in a way analog to the aforementioneddescriptions, especially in accordance with the operation S1.24described in connection with the client—server communication.

In an operation S1.25, the generated request response and the cookie aretransmitted to the client.

The following description with reference to FIG. 1 b may describe theprofile and session management with respect to subsequent clientrequests during an established session, according to the concept basedon an embodiment of the present invention.

FIG. 1 b shows a flow diagram illustrating a sequence of processingoperations with respect to the operation of a server and a gateway,respectively, according to an embodiment of the invention. Theillustrated sequence will be described in view of client—servercommunication and client—gateway communication analog to the descriptionwith respect to FIG. 1 a.

Client—Server Communication:

In an operation S1.10, a subsequent request operation is started. Acorresponding profile and session management is opened or establishedand the corresponding access information is available to client andserver.

In an operation S1.11, the server receives a subsequent request from theclient. The subsequent client request comprises a cookie. The cookiecomprises referencing and session information. The session informationand the referencing information allow the server to retrieve theinformation cached, i.e. the UAProf information transmitted at theestablishment and opening of the corresponding client-related session.Therefore, referencing and session information identifies uniquely theclient and references uniquely the cached UAProf information.

Additional control sequences may be included in the cookie comprisingthe referencing and session information. Control sequences may be usedto indicate certain control functions of the session management. Theclient may update the cached information of a currently active session.Further, the client may suspend a currently active session or the clientmay resume a suspended session. To update the information cached byserver, the client may transmit a request comprising the UAProfconcerning information, i.e. the profile and the profile differencescoded in the header of the request and an accompanying control sequenceinstructing the server to update the cached information. The sessionitself is maintained whereas the UAProf information is updated.Analogously, a session may be suspended. During the lifespan of anestablished session, the session managing and profile caching server hasto cache all negotiated information relevant to session and profile. Thesuspended session does not entail parsing connected to the cachingoperation. Correspondingly, a control sequence may be issued to resumesuch a suspended session. The resume sequence forces an update operationof the cached profile to ensure that valid information is kept in thecache.

In an operation S1.12, the cached profile data are received.Particularly, cached UAProf information is retrieved.

In an operation S1.13, a response in accordance with the client requestis generated. The generating operation takes into account the retrievedUAProf information by e.g. adapting or modifying the request response tomeet the needs and requirements of the client defined in the UAProfinformation. Additionally, a cookie may be generated comprising statusinformation taking into account the UAProf information. Furtherinformation with reference to the session managing may be included.

In an operation S1.14, the request response and the cookie aretransmitted to the client.

In an operation S1.15, the operational sequence of a subsequent requestduring an established session and profile management is finished.

Client—Gateway Communication:

According to the following description, the operations S1.10 to S1.12are operated by an intermediate network device such as a gateway and aproxy, respectively, in the same manner compared with the aforementionedoperations S1.10 to S1.12 referencing to the Client—ServerCommunication.

Profile and Session Managing Server:

In order to identify the session managed by a subsequent server, therequest or the cookie transmitted from the client may have to includeadditional referencing and session information in accordance with theprofile and session managing of the server, in order to enable theretrieval of the profile data by the server. It may be further possiblethat this additional referencing and session information is cachedadditionally together with the profile data retrieved in the operationS1.12.

In an operation S1.16, a server request and a cookie is generated. Theserver request is based on the client request and the cookie comprisesreferencing and session information in accordance with the profile andsession management of the server. The generating operation may be aconversion process analog to the operation S1.27 illustrated in FIG. 1a.

In an operation S1.17, the server request is transmitted to the server.

The following operations S1.18 and S1.13 are operated analogously to theoperation S1.29 and S1.24 described in accordance with theClient—Gateway Communication section of the profile and session managingserver.

In an operation S1.18, a server request is received. The server haspreferably operated the operations S1.10 to S1.15 according to theaforementioned description referring to a server according to anembodiment of the invention. Correspondingly, the server response to therequest comprises a server response cookie. This server response cookiecomprises referencing and session information of the UAProf caching andsession management of the server, and correspondingly may comprise acorresponding signaling sequence as described above.

In an operation S1.13, the intermediate network device generates aresponse to the client request based on the server response. Thegeneration may comprise a conversion operation e.g. to convert theserver response information coded in a certain transfer protocol into atransfer protocol suitable for communication with the client. Thegenerating operation may additionally take into account the UAProfinformation according to the version cached by the intermediate networkdevice. Referencing and session information of both the intermediatenetwork device and the server is available. This Referencing and sessioninformation may be coded in two different cookies and added to theresponse to the client request, or may be coded in a single cookiecomprising the complete information and added to the response. Thecorresponding information for subsequent accesses to the intermediatenetwork device and the server is available to the client in both cases.

In an operation S1.14, the response to the request and the cookie aretransmitted to the client.

Non-Session Managing Server:

The following operations S1.16 to S1.18 and S1.13 to S1.14 are operatedanalogously to the operations S1.27 to S1.29 and S1.24 to S1.25described in accordance with the client—gateway communication section ofa non-session managing server. Correspondingly, the description may belooked up above at the referenced section.

The following FIGS. 2 a and 2 b illustrate the plurality of apparatusand systems able to operate the aforementioned embodiments of the methodaccording to the present invention. A detailed description of theinteraction of the illustrated apparatus and systems will be given incombination with the following description of the FIGS. 3 a and 3 b.

FIG. 2 a shows a block diagram illustrating a system of a client and aserver according to an embodiment of the invention.

The client 100 may be a mobile terminal device, preferably a mobilephone. The mobile phone may operate a WAP/WEB browser. This browser isable to generate requests for a corresponding WAP/WEB server, e.g.requests requesting certain WAP/WEB pages, and is able to receivecorresponding responses, e.g. responses comprising WAP/WEB pages to bedisplayed.

The server 200 may be the corresponding WAP/WEB server addressed by theclient requests. The communication of the requests and the responses maybe operated via communication networks, which may comprise a wirelesscommunication network and a wireline communication network. Intermediatenetwork devices (not shown) may be involved in the routing of therequests and responses. A WAP proxy or gateway may connect the wirelesscommunication network and wireline communication network in order toconvert the transfer protocols.

The server 200 comprises a communication interface 230, a sessionmanager 210 for managing the session and cached information in a cache211, and a serving component 220 for generating a response based on aclient request. The serving component 220 may access a server content221 providing data that may be requested by the client request.

The communication interface 230 may be constituted by a data processingdevice or a program section executed at the server 200 in connection tothe client 100 via the above described communication network. Thecommunication interface 230 may be realized by a server executablescript or a program section executed at the server 200. The sessionmanager 210 and the serving component 220 may be constituted by a dataprocessing device or a program section executed at the server 200. Thesession manager 210 and the serving component 220 may be realized by aserver executable script or a program section executed at the server200.

FIG. 2 b shows a block diagram illustrating a system of a client,intermediate gateway and a server according to an embodiment of theinvention.

The client 100 may be a mobile terminal device, preferably a mobilephone. The mobile phone may operate a WAP/WEB browser. This browser isable to generate requests for a corresponding WAP/WEB server, e.g.requests requesting certain WAP/WEB pages, and is able to receivecorresponding responses, e.g. responses comprising WAP/WEB pages to bedisplayed.

The server 201 comprises a communication interface 231, a servingcomponent 220 for generating a response based on a client request. Theserving component 220 may access a server content 221 providing datathat may be requested by the client request.

The communication interface 231 may be constituted by a data processingdevice or a program section executed at the server 201 in connection tothe proxy/gateway 300 via the above described communication network. Thecommunication interface 231 may be realized by a server executablescript or a program section executed at the server 201. The servingcomponent 220 may be constituted by a data processing device or aprogram section executed at the server 201. The serving component 220may be realized by a server executable script or a program sectionexecuted at the server 201.

The proxy/gateway 300 comprises a communication interface 330 enablingthe communication with the client 100, and a communication interface 331enabling the communication with the server 201. The communicationinterface 330 may allow communication with the client 100 via a transferprotocol adapted to wireless communication. The communication interface331 may allow communication with the server 201 via a transfer protocoladapted to wireline communication. A common communication interface (notshown) may offer the functionality of both the communication interface330 and the communication interface 331. Further, the proxy/gateway 300comprises a session manager 310 for managing the session and cachedinformation in a cache 311, and a serving component 320 for generating aresponse based on a client request and based on the server response.

The communication interface 330 may be constituted by a data processingdevice or a program section executed at the proxy/gateway 300 inconnection to the client 100 via the above described communicationnetwork. The communication interface 330 may be realized by a serverexecutable script or a program section executed at the proxy/gateway300. The communication interface 331 may be constituted by a dataprocessing device or a program section executed at the proxy/gateway 300in connection to the server 201 via the above described communicationnetwork. The communication interface 331 may be realized by a serverexecutable script or a program section executed at the proxy/gateway300.

The session manager 310 and the serving component 320 may be constitutedby a data processing device or a program section executed at theproxy/gateway 300. The session manager 310 and the serving component 320may be realized by a server executable script or a program sectionexecuted at the proxy/gateway 300.

Further intermediate network devices (not shown) may be involved in therouting of the requests and responses.

FIG. 3 a shows a flow diagram illustrating a timely sequence of theoperations with respect to FIG. 2 a and according to an embodiment ofthe invention. The operational sequence shown in FIG. 3 a according tothe apparatus and system illustrated in FIG. 2 a corresponds to theclient—server communication described in FIG. 1 a and FIG. 1 b. Thefollowing description may extend the above-presented description.Therefore, references back to the FIG. 2 a will be given.

The operations S3.11 to S3.18 are dedicated to the processing of aninitial request, and the establishment of the profile and sessionmanagement. The operations S3.21 to S3.28 are dedicated to subsequentrequests during an established and opened profile and sessionmanagement.

In an operation S3.11, the client 100 transmits an initial request. Thisrequest may be generated by an application executed at the client 100,such as the illustrated WAP/WEB browser. This initial request comprisesinformation of the UAProf in order to establish a profile and sessionmanagement according to the concept and embodiments of the presentinvention. This request is addressed to the server 200.

The server 200 may be an HTTP-based server and the client 100 may be amobile phone. A gateway/proxy 305 may convert the request orcorrespondingly a following response. This gateway/proxy 305 is notshown in FIG. 2 a since gateway/proxy 305 is not further involved in theoperational sequence. In an operation S3.12 the client request isforwarded to the server 200.

In an operation S3.13, the communication interface 231 of the server 200receives the transmitted client request of client 100.

In an operation S3.14, the session manager 210 of the server 200 mayextract the UAProf information from the client request and cache theinformation in the cache 211. Furthermore, the session manager maygenerate a referencing and session information uniquely referring to thecached UAProf information and uniquely identifying the session.

In an operation S3.15, the serving component 220 of the server 200generates a response to the request based on the client request. Theserving component 220 may have access to a content 221 for retrievinginformation necessary to generate the response. The generation of theresponse further takes into account the UAProf information and adaptsthe response thereto. The serving component 220 may further generate aresponse cookie comprising the referencing and session informationgenerated by the session manager 210. The cookie may be appended to theresponse. Subsequently, the response to the request and the cookie aretransmitted by the communication interface 231 to the client 100.

In an operation S3.16, the request is forwarded by proxy/gateway 305 tothe client 100.

In an operation S3.17, the client 100 receives the response to itsrequest and the cookie from the server 200. The response may be suppliedto the receiving application for further processing. In an operationS3.18, the cookie or the information included in the cookie may bestored in order to be employed for subsequent client requests.

In an operation S3.21, a subsequent request may be generated by anapplication running on the client 100, for example a WAP/WEB browserrequesting a WAP/WEB page for displaying. A cookie is appended to theclient request comprising the referencing and session information inorder to identify the session. The subsequent request and the cookie areaddressed to the server 200 and transmitted thereto.

In an operation S3.22, a proxy/gateway forwards the client request. Theforwarding may be operated analogously to the forwarding operationS3.12.

In an operation S3.23, the communication interface 231 of the server 200receives the request and the cookie.

In an operation S3.24, the session manager 210 of the server 200 mayextract the referencing and session information from the cookie, andretrieves correspondingly the profile data from the cache 211, i.e. thepreviously cached UAProf information.

In an operation S3.25, the serving component 220 of the server 200generates a response to the request based on the client request. Theserving component 220 may have access to a content 221 for retrievinginformation necessary to generate the response. The generation of theresponse further takes into account the UAProf information and adaptsthe response thereto. The serving component 220 may further generate aresponse cookie comprising the status information with reference to thetaking account of the UAProf information and/or referencing and sessioninformation in case of a necessary update of the referencing and sessioninformation stored at the client 100. The cookie may be appended to theresponse. Subsequently, the response to the request is transmitted bythe communication interface 231 to the client 100.

In an operation S3.26, the request may be forwarded by proxy/gateway 305to the client 100.

In an operation S3.27, the client 100 receives the response to itsrequest and the cookie from the server 200. The response may be suppliedto the receiving application for further processing. In an operationS3.28, the cookie or the information included in the cookie may bestored. The storing may be an update of a previously stored cookieinformation.

FIG. 3 b shows a flow diagram illustrating a timely sequence of theoperations with respect to FIG. 2 b and according to an embodiment ofthe invention. The operational sequence shown in FIG. 3 b, according tothe apparatus and system illustrated in FIG. 2 b, corresponds to theclient—getaway communication described in FIG. 1 a and FIG. 1 b. Thefollowing description may extend the above-presented description.Therefore references back to the FIG. 2 b will be given.

The operations S4.10 to S4.19 are dedicated to the processing of aninitial request and the establishment of the profile and sessionmanagement. The operations S4.20 to S4.29 are dedicated to subsequentrequests during an established and opened profile and sessionmanagement.

In an operation S4.10 the client 100 transmits an initial request. Thisrequest may be generated by an application executed at the client 100,such as the illustrated WAP/WEB browser. This initial request comprisesinformation of the UAProf in order to establish a profile and sessionmanagement according to the concept and embodiments of the presentinvention. This request is addressed to the server 201.

In an operation S4.11, the communication interface 330 of thegateway/proxy 300 receives the transmitted client request of client 100.

In an operation S4.12, the session manager 310 of the gateway/proxy 300may extract the UAProf information from the client request and cache theinformation in the cache 311. Furthermore, the session manager maygenerate a referencing and session information uniquely referring to thecached UAProf information and uniquely identifying the session.

In an operation S4.13, the client request is forwarded to the server201. The forwarding may entail generating a server request correspondingto the original client request and/or a conversion of the transferprotocol. The server request also comprises the UAProf information. Thecommunication interface 331 of the gateway/proxy 300 transmits theserver request to the server 201.

In an operation S4.14, the communication interface 231 of the server 201receives the server request.

In an operation S4.15 the serving component 220 of the server 201generates a server response to the request based on the server requestor the client request, respectively. The serving component 220 may haveaccess to a content 221 for retrieving information necessary to generatethe server response. The generation of the response further takes intoaccount the UAProf information and adapts the server response thereto.Subsequently, the response to the request is transmitted by thecommunication interface 231 to the gateway/proxy 300.

In an operation S4.16, the communication interface 331 of thegateway/proxy 300 receives the server response.

In an operation S4.17, a response to the client request may be generatedbased on the server response. The gateway/proxy 300 may take the UAProfinto account and adapt the generated response thereto. It has to beguaranteed that the response to the client request meets the needs andrequirements in accordance with the UAProf information of the client100. The serving component 320 may further generate a response cookiecomprising the referencing and session information generated by thesession manager 310. The cookie may be appended to the response.Subsequently, the response and the cookie are transmitted by thecommunication interface 330 to the client 100.

In an operation S4.18, the client 100 receives the response to itsrequest and the cookie from the gateway/proxy 300. The response may besupplied to the receiving application for further processing. In anoperation S4.19, the cookie or the information comprised by the cookiemay be stored in order to be employed for subsequent client requests.

In an operation S4.20, a subsequent request may be generated by anapplication running on the client 100, for example a WAP/WEB browserrequesting a WAP/WEB page for displaying. A cookie is appended to theclient request comprising the referencing and session information inorder to identify the session. The subsequent request and the cookie aretransmitted to the gateway/proxy 300.

In an operation S4.21, the communication interface 330 of thegateway/proxy 300 receives the transmitted client request of client 100.

In an operation S4.22, the session manager 310 of the gateway/proxy 300may extract the referencing and session information from the cookie andretrieve correspondingly the profile data from the cache 311, i.e. thepreviously cached UAProf information.

In an operation S4.23, a server request is generated based on theoriginal client request. The generating may comprise a conversion of thetransfer protocol. The server request further comprises the cachedUAProf information retrieved in operation S4.22. The communicationinterface 331 of the gateway/proxy 300 transmits the server request tothe server 201.

In an operation S4.24, the communication interface 231 of the server 201receives the server request.

In an operation S4.25 the serving component 220 of the server 201generates a server response based on the server request. The servingcomponent 220 may have access to a content 221 for retrievinginformation necessary to generate the server response. The generation ofthe response further takes the UAProf information into account andadapts the server response thereto. Subsequently, the response to therequest is transmitted by the communication interface 231 to thegateway/proxy 300.

In an operation S4.26, the communication interface 331 of thegateway/proxy 300 receives the server response.

In an operation S4.27, a response to the client request is generatedbased on the server response. The gateway/proxy 300 may consider theUAProf and may additionally adapt the generated response thereto. It hasto be guaranteed that the response to the client request meets the needsand requirements in accordance with the UAProf information of the client100. The serving component 320 may further generate a response cookiecomprising the status information with reference to the taking accountof the UAProf information and/or referencing and session information incase of a necessary update of the referencing and session informationstored at the client 100. The cookie may be appended to the response.Subsequently, the response to the client request and the cookie aretransmitted by the communication interface 330 to the client 100.

In an operation S4.28, the client 100 receives the response to itsrequest and the cookie from the gateway/proxy 300. The response may besupplied to the receiving application for further processing. In anoperation S4.29, the cookie or the information included in the cookiemay be stored. The storing may be an updating of a previously storedcookie information.

FIG. 4 a shows a flow diagram illustrating a sequence of processingoperations with respect to the operation of a server and a gateway,respectively, according to an embodiment of the invention. The sequenceof processing operations illustrates the establishment of the profileand session management in accordance with an initial client request. Dueto the interaction of processing devices within an end-to-endcommunication chain, the concept of the present invention will bedescribed with reference to a terminal client and a terminal server, asalso to a terminal client and an intermediate network device i.e. aninteracting gateway or proxy.

Client—Server Communication:

The following operations are dedicated to and operated by a servercommunicating with a client, both supporting the profile and sessionmanagement according to an embodiment of the present invention.

In an operation S5.20, the initial request operation is started.

In an operation S5.21, a server receives an initial request. The initialrequest comprises, according to the description above, user agentprofile (UAProf) information. The server recognizes on the basis of thecomprised UAProf and due to an original unmodified uniform resourcelocator (URL) used for addressing the client request, that a session hasto be opened and the initial UAProf information has to be established.For example, the request may instruct a server to generate andretransmit a WAP/WEB page in accordance with the provided URL“http://www.nokia.com/main.html”.

In an operation S5.22, the initial UAProf information is cached. TheUAProf information may be optionally modified by the server by addingserver related UAProf information, reflecting information only availableby the server.

In an operation S5.23, referencing and session information is obtained.The referencing information comprises a code sequence by which thecached UAProf information is accessible and retrievable, i.e. this codesequence may be termed as a pointer pointing to the cached UAProfinformation. Further, the referencing information may additionally codea unique session identification, such that the server may identify asubsequent client request as belonging to this established session.

In an operation S5.24, a response in accordance with the client requestis generated. For example, the generated response may comprise followingsequence:

-   -   <html><body>    -   <a href=“http://www.nokia.com/page2.hml”>Follow this link to the        next page</a>    -   </body></html>

In an operation S5.25, the uniform resource locators (URL) comprised inthe generated response are processed. In order to inform the client ofthe established session and to put the client in the position totransmit a unique session identifying information upon subsequentrequests to the same server, the generated referencing and sessioninformation may be appended to the uniform resource locators (URL)included in the generated response. Adding a signaling sequence mayfurther complete the coding of the aforementioned referencing andsession information.

According to the above-presented exemplary sequence included in theresponse, the modification may result in the following sequence:

-   -   <html><body>    -   <a href=“http://www.nokia.com/page2.hml?uaprofidNAWG094719        3=123554”>Follow this link to the next page</a>    -   </body></html>

Herein, the referencing and session information may be composed of afirst part of a sequence “uaprofidNAWG0947193” and a second part of asequence “123554”. The first part of the sequence may represent thereferring information for retrieving the cached profile data, i.e. theUAProf information, whereas the second part of the sequence mayrepresent a session identifier.

In an operation S5.26, the generated response to the request comprisingmodified URLs is transmitted to the client.

In an operation S5.27, the operational sequence in accordance with theinitial client request is finished.

Client—Gateway Communication:

The following operations are dedicated to and operated by anintermediate network device communicating with a client, both supportingthe profile and session management according to an embodiment of thepresent invention. Advantageously, the description of the Client—GatewayCommunication may distinguish between a server supporting the profileand session management according to an embodiment of the presentinvention, and a conventional server that does not support sessions.

In both cases the intermediate network device operates the operationsS5.20 to S5.23 in the same manner compared with the aforementionedoperations S5.20 to S5.23 referencing to the Client—ServerCommunication. The operation S5.22 may comprise a modification operationin accordance with the tasks of an intermediate negotiating networkdevice, herein described with reference to an intermediate networkdevice, respectively. The UAProf information may be optionally modifiedby the intermediate network device by adding server related UAProfinformation, reflecting information only available by the intermediatenetwork device, e.g. to better meet the needs of the requesting client.The operation S5.24 comprises a plurality of additional operationsreferring to the server communication.

Profile and Session Managing Server:

In an operation S5.28, a server request is generated based on the clientrequest. The referencing and session information relating to theintermediate network device is removed. Further, the generation of theserver request may be a conversion of the client request. The clientrequest may be based on another transfer protocol as the server request.The information contained in the client request may be taken overwithout modifying the content of the information. For example, a clientrequest is received based on WAP and has to be forwarded to an HTTPbased server. Correspondingly, the intermediate network device convertsthe client request. The comprised user agent profile (UAProf)information is maintained by the generating operation. In case of aprior modification of the UAProf described in operation S5.24, themodified user agent profile (UAProf) information may be included in thegenerated server request.

In an operation S5.29, the server request is transmitted to the server.

In an operation S5.30, a server response to the request is received. Theserver has preferably operated the operations S1.20 to S1.27 accordingto the aforementioned description referring to the Client—ServerCommunication according to an embodiment of the present invention. URLscontained in the server response may be modified by appendingreferencing and session information of the UAProf caching and sessionmanaging of the server, and correspondingly may comprise a correspondingsignaling sequence described above.

In an operation S5.24, the intermediate network device generates aresponse to the client request based on the server response. Thegeneration may comprise a conversion operation e.g. to convert theserver response information coded in a certain transfer protocol into atransfer protocol suitable for communication with the client. Thegenerating operation may take additionally the UAProf information intoaccount according to the version cached by the intermediate networkdevice. For example, the cached UAProf information may be taken intoaccount in case that the generated response does not fulfil allrequirements of the client due to an incomplete considering of theUAProf information by the server, e.g. due to lacking servercapabilities.

In an operation S5.25, the uniform resource locators (URL) contained inthe generated response are processed. In order to inform the client ofthe established session and to put the client in the position totransmit a unique session identifying information upon subsequentrequests to the same server, the generated referencing and sessioninformation may be appended to the uniform resource locators (URL)contained in the generated response. Adding a signaling sequence mayfurther complete the coding of the aforementioned referencing andsession information. The URLs may comprise now two different referencingand session informations according to the server and the intermediatenetwork device, which do not interfere with each other.

Non-Session Managing Server:

In an operation S5.28, a server request is generated. The generation ofthe server request is performed analogously to the generating operationS5.28 described above with reference to the profile and session managingserver.

In an operation S5.29, the server request is transmitted to the server.

In an operation S5.30, the intermediate network device receives thecorresponding server response to the request. According to thecapability of the server, the received server response may be based onthe transmitted UAProf comprised in the server request or the server mayhave not considered the provided UAProf.

In an operation S5.24, the generating operation may additionally takethe UAProf information into account according to the version cached bythe intermediate network device. For example, the cached UAProfinformation may be taken into account in case that the generatedresponse does not fulfil all requirements of the client due to anincomplete considering of the UAProf information by the server, e.g. dueto lacking server capabilities. Particularly, the intermediate networkdevice may take the UAProf information during the generating operationinto consideration in case of a server which is not capable to considerthe transmitted UAProf information adequately.

The further operations S5.25 and S5.26 are operated analogously to theoperation S5.25 and S5.26 described above with reference to theClient—Server Communication.

The following description with reference to FIG. 4 b may describe theprofile and session managing with respect to subsequent client requestsduring an established session according to the concept basing on anembodiment of the present invention.

FIG. 4 b shows a flow diagram illustrating a sequence of processingoperations with respect to the operation of a server and a gateway,respectively, according to an embodiment of the invention. Theillustrated sequence will be described in view of client—servercommunication and client—gateway communication analog to the descriptionwith respect to FIG. 4 a.

Client—Server Communication:

In an operation S5.50, a subsequent request operation is started. Acorresponding profile and session management is opened or establishedand the corresponding access information is available to client andserver.

In an operation S5.51, the server receives a subsequent request from theclient. The subsequent client request comprises a URL includingreferencing and session information. The session information and thereferencing information allows the server to retrieve the informationcached, i.e. the UAProf information transmitted at the establishment andopening of the corresponding client related session. Therefore,referencing and session information identifies uniquely the client andreferences uniquely the cached UAProf information. Additional controlsequences may be included in the URL comprising the referencing andsession information.

In an operation S5.52, the cached profile data are received.Particularly, cached UAProf information is retrieved.

In an operation S5.53, a response in accordance with the client requestis generated. The generating operation takes into account the retrievedUAProf information by e.g. adapting or modifying the response to meetthe needs and requirements of the client defined in the UAProfinformation.

In an operation S5.54, the uniform resource locators (URL) contained inthe generated response are processed. In order to inform the client ofthe established session and to put the client in the position totransmit a unique session identifying information upon subsequentrequests to the same server, the generated referencing and sessioninformation may be appended to the uniform resource locators (URL)contained in the generated response. Adding a signaling sequence mayfurther complete the coding of the aforementioned referencing andsession information.

In an operation S5.55, the generated response to the request, comprisingmodified URLs, is transmitted to the client.

In an operation S5.56, the operational sequence in accordance with theinitial client request is finished.

Client—Gateway Communication:

According to the following description, the operations S5.50 and S5.53to S5.55 are operated by an intermediate network device in the samemanner as with the aforementioned operations S5.30 and S5.25 to S5.26referencing to the Client—Server Communication.

Profile and Session Managing Server:

In order to identify the session managed by a subsequent server, therequest may have to comprise additional referencing and sessioninformation in accordance with the profile and session management of theserver, in order to enable the retrieval of the profile data by theserver. Several referencing and session information according to profileand session management of different network devices can be coded withinthe modified URL, e.g. by appending successively the individual networkrelating referencing and session information.

In an operation S5.57, a server request is generated. The server requestis based on the client request. The referencing and session informationincluded in the uniform resource locator (URL) and relating to theprofile and session management of the intermediate network device isremoved. The resulting uniform resource locator (URL) is employed forthe addressing of the server request. The generating operation may be aconversion process analog to the operation S5.28 illustrated in FIG. 1a.

In an operation S5.58, the server request is transmitted to the server.

The following operations S5.59 and S5.53 are operated analogously to theoperation S5.30 and S5.24 described in accordance with theclient—gateway communication section of the profile and session managingserver.

In an operation S5.59, a server request is received. The server haspreferably operated the operations S5.50 to S5.56 according to theaforementioned description referring to a server according to anembodiment of the invention. Correspondingly, the server response to therequest comprises modified URLs including referencing and sessioninformation of the UAProf caching and session management of the serverand optionally a signaling sequence described above.

In an operation S5.53, the intermediate network device generates aresponse to the client request based on the server response. Thegeneration may comprise a conversion operation e.g. to convert theserver response information coded in a certain transfer protocol into atransfer protocol suitable for communication with the client. Thegenerating operation may additionally take the UAProf information intoaccount according to the version cached by the intermediate networkdevice. Referencing and session information of both the intermediatenetwork device and the server is available.

In an operation S5.54, the uniform resource locators (URL) containedwithin the generated response are processed. In order to inform theclient of the established session and to put the client in the positionto transmit a unique session identifying information upon subsequentrequests to the same server, the generated referencing and sessioninformation may be appended to the uniform resource locators (URL)contained in the generated request response. Adding a signaling sequencemay further complete the coding of the aforementioned referencing andsession information. The URLs may comprise now two different referencingand session information according to the server and the intermediatenetwork device, which do not interfere with each other.

In an operation S5.55, the response is transmitted to the client.

Non-Session Managing Server:

The following operations S5.57 to S5.59 and S5.54 to S5.55 are operatedanalogously to the operations S5.28 to S5.30 and S5.24 to S5.26described in accordance with the client—gateway communication section ofa non-session managing server. Correspondingly, the description may bereferred to above at the referenced section.

FIG. 5 a shows a flow diagram illustrating a sequence of the operationswith respect to FIG. 2 a and according to an embodiment of theinvention. The operational sequence shown in FIG. 5 a according to theapparatus and system illustrated in FIG. 2 a corresponds to theclient—server communication described in FIG. 4 a and FIG. 4 b. Thefollowing description may extend the above-presented description.Therefore references back to the FIG. 2 a will be given.

The operations S6.11 to S6.17 are dedicated to the processing of aninitial request and the establishment of the profile and sessionmanagement. The operations S6.21 to S6.27 are dedicated to subsequentrequests during an established and opened profile and sessionmanagement.

In an operation S6.11 the client 100 transmits an initial request. Thisrequest may be generated by an application executed at the client 100,such as the illustrated WAP/WEB browser. This initial request comprisesinformation of the UAProf in order to establish a profile and sessionmanagement according to the concept and embodiments of the presentinvention. This request is addressed to the server 200.

The server 200 may be an HTTP-based server and the client 100 may be amobile phone. A gateway/proxy 305 may convert the request orcorrespondingly a following response. This gateway/proxy 305 is notshown in FIG. 2 a since gateway/proxy 305 is not further involved in theoperational sequence. In an operation S6.12 the client request isforwarded to the server 200.

In an operation S6.13, the communication interface 231 of the server 200receives the transmitted client request of client 100.

In an operation S6.14, the session manager 210 of the server 200 mayextract the UAProf information from the client request and cache theinformation in the cache 211. Further, the session manager may generatea referencing and session information uniquely referring to the cachedUAProf information and uniquely identifying the session.

In an operation S6.15, the serving component 220 of the server 200generates a response to the request based on the client request. Theserving component 220 may have access to a content 221 for retrievinginformation necessary to generate the response. The generation of theresponse further takes the UAProf information into account and adaptsthe response thereto. The URLs contained in the response are processed.The referencing and session information is appended to each URL.

In an operation S6.16, the request is forwarded by the proxy/gateway 305to the client 100.

In an operation S6.17, the client 100 receives the response to itsrequest from the server 200. The response may be supplied to thereceiving application for further processing.

In an operation S6.21, a subsequent request may be generated by anapplication running on the client 100, for example a WAP/WEB browserrequesting a WAP/WEB page for displaying. The modified uniform resourcelocator (URL) of the client request comprises the referencing andsession information in order to identify the session. The subsequentrequest is transmitted to the server 200.

In an operation S6.22, a proxy/gateway forwards the client request. Theforwarding may be operated analogously to the forwarding operationS3.12.

In an operation S6.23, the communication interface 230 of the server 200receives the request.

In an operation S6.24, the session manager 210 of the server 200 mayextract the referencing and session information from the URL of theclient request, and retrieves correspondingly the profile data from thecache 211, i.e. the previously cached UAProf information.

In an operation S6.25, the serving component 220 of the server 200generates a response to the request based on the client request. Theserving component 220 may have access to a content 221 for retrievinginformation necessary to generate the response. The generation of theresponse further takes the UAProf information into account and adaptsthe response thereto. Additionally, the serving component 220 furtherprocesses the URLs contained in the generated response by appendingreferencing and session information. Subsequently, the response to therequest is transmitted by the communication interface 230 to the client100.

In an operation S6.26, the request may be forwarded by the proxy/gateway305 to the client 100.

In an operation S6.27, the client 100 receives the request response fromthe server 200. The response may be supplied to the receivingapplication for further processing.

FIG. 5 b shows a flow diagram illustrating a timely sequence of theoperations with respect to FIG. 2 b and according to an embodiment ofthe invention. The operational sequence shown in FIG. 5 b according tothe apparatus and system illustrated in FIG. 2 b corresponds to theclient—gateway communication described in FIG. 4 a and FIG. 4 b. Thefollowing description may extend the above presented description.Therefore references back to the FIG. 2 b will be given.

The operations S7.10 to S7.18 are dedicated to the processing of aninitial request and the establishment of the profile and sessionmanagement. The operations S7.20 to S7.28 are dedicated to subsequentrequests during an established and opened profile and sessionmanagement.

In an operation S7.10 the client 100 transmits an initial request. Thisrequest may be generated by an application executed at the client 100,such as the illustrated WAP/WEB browser. This initial request comprisesUAProf information in order to establish a profile and sessionmanagement according to the concept and embodiments of the presentinvention. This request is addressed to the server 201.

In an operation S7.11, the communication interface 330 of thegateway/proxy 300 receives the transmitted client request of client 100.

In an operation S7.12, the session manager 310 of the gateway/proxy 300may extract the UAProf information from the client request and cache theinformation in the cache 311. Further, the session manager may generatea referencing and session information uniquely referring to the cachedUAProf information and uniquely identifying the session.

In an operation S7.13, the client request is forwarded to the server201. The forwarding may comprise a generating of a server requestcorresponding to the original client request and/or a conversion of thetransfer protocol. The server request also comprises the UAProfinformation. The communication interface 331 of the gateway/proxy 300transmits the server request to the server 201.

In an operation S7.14, the communication interface 231 of the server 201receives the server request.

In an operation S7.15 the serving component 220 of the server 201generates a server response to the request based on the server requestor the client request, respectively. The serving component 220 may haveaccess to a content 221 for retrieving information necessary to generatethe server response. The generation of the response further takes theUAProf information into account and adapts the server response thereto.Subsequently, the response to the request is transmitted by thecommunication interface 231 to the gateway/proxy 300.

In an operation S7.16, the communication interface 331 of thegateway/proxy 300 receives the server request response.

In an operation S7.17, a response to the client request may be generatedbased on the server response. The gateway/proxy 300 may take the UAProfinto account and adapt the generated response thereto. It has to beguaranteed that the response to the client request meets the needs andrequirements in accordance with the UAProf information of the client100. The serving component 320 further processes the URLs contained inthe generated response. The referring and session information generatedby the session manager 310 may be appended to the comprised URLs.Subsequently, the response is transmitted by the communication interface330 to the client 100.

In an operation S7.18, the client 100 receives the request response fromthe gateway/proxy 300. The response may be supplied to the receivingapplication for further processing. Further subsequent responses may bebased on the modified URLs comprised in the received response.

In an operation S7.20, a subsequent request may be generated by anapplication running on the client 100, for example a WAP/WEB browserrequesting a WAP/WEB page for displaying. The request may be initiatedby selecting a modified URL for following the link. The subsequentrequest is transmitted to the gateway/proxy 300.

In an operation S7.21, the communication interface 330 of thegateway/proxy 300 receives the transmitted client request of client 100.

In an operation S7.22, the session manager 310 of the gateway/proxy 300may extract the referencing and session information from the URLcontained within the client request, and retrieves correspondingly theprofile data from the cache 311, i.e. the previously cached UAProfinformation.

In an operation S7.23, a server request is generated based on theoriginal client request. The generation may entail a conversion of thetransfer protocol. The server request further comprises the cachedUAProf information retrieved in operation S7.22. The URL may be set toits original state by removing the referencing and session informationreferring to the profile and session management of the gateway/proxy300. The communication interface 331 of the gateway/proxy 300 transmitsthe server request to the server 201.

In an operation S7.24, the communication interface 230 of the server 201receives the server request.

In an operation S7.25 the serving component 220 of the server 201generates a server response to the request based on the server request.The serving component 220 may have access to a content 221 forretrieving information necessary to generate the server response. Thegeneration of the response further takes the UAProf information intoaccount and adapts the server response thereto. Subsequently, theresponse to the request is transmitted by the communication interface231 to the gateway/proxy 300.

In an operation S7.26, the communication interface 331 of thegateway/proxy 300 receives the server response.

In an operation S7.27, a response to the client request is generatedbased on the server response. The gateway/proxy 300 may take the UAProfinto consideration and may additionally adapt the generated responsethereto. It has to be guaranteed that the response to the client requestmeets the needs and requirements in accordance with the UAProfinformation of the client 100. The serving component 320 furtherprocesses the URLs contained within the generated client response. Thereferring and session information generated by the session manager 310may be appended to the comprised URLs. Subsequently, the response to therequest is transmitted by the communication interface 330 to the client100.

In an operation S7.28, the client 100 receives the response to itsrequest comprising modified URL from the gateway/proxy 300. The responsemay be supplied to the receiving application for further processing.

This specification contains the description of implementations andembodiments of the present invention with the help of examples. A personskilled in the art will appreciate that the present invention is notrestricted to details of the embodiments presented above, and that theinvention can be also implemented in another form without deviating fromthe characteristics of the invention. The embodiment presented aboveshould be considered as illustrative, but not restricting. Thus, thepossibilities of implementing and using the invention are onlyrestricted to the enclosed claims. Consequently, various options ofimplementing the invention as determined by the claims, includingequivalent implementations, also belong to the scope of the invention.

1. Method for providing profile data to a requesting device, comprisingthe steps of: receiving (S1.11) a request and an associated cookie fromsaid requesting device (100), said cookie comprising information forretrieving said profile data, retrieving (S1.12) said profile data,generating (S1.13) a response in accordance with said request, saidresponse being based on said profile data; generating (S1.13) a responsecookie comprising session information, and transmitting (S1.14) saidresponse and response cookie to said requesting device (100).
 2. Methodfor providing profile data to a requesting device, comprising the stepsof: receiving (S5.51) a request for data from said requesting device(100), wherein said request has a uniform resource locator (URL)referring to said data being requested and comprising information forretrieving profile data, retrieving (S5.52) said profile data,generating (S5.53) a response in accordance with said request, whereinsaid response is based on said profile data and includes a plurality ofuniform resource locators (URLs), processing (S5.54) said uniformresource locators (URLs) by including therein information for retrievingprofile data, and transmitting (S5.55) said response to said requestingdevice (100).
 3. Method according to claim 1, wherein said profile dataare available for being retrieved for a certain period of time. 4.Method according to claim 3, wherein said period of time starts with theinitial receiving of said profile data.
 5. Method according to claim 4,wherein said period of time is terminated with the removal of saidprofile data.
 6. Method according to claim 1, wherein said step ofgenerating a response further comprises the steps of; generating (S1.27,S1.16, S5.28, S5.57) a server request based on the client request,transmitting (S1.28, S1.17, S5.29, S5.58) said server request, receiving(S1.29, S1.18, S5.30, S5.59) a server response in accordance with saidserver request and generating (S1.24, S1.13, S5.24, S5.53) a responsebased on said server response.
 7. Method according to claim 1, whereinsaid request is a request to a WEB- or WAP-server.
 8. Method accordingto 1, wherein said method is applicable to the hypertext transportprotocol (HTTP).
 9. Software tool for providing profile data, comprisingprogram code portions for carrying out the operations of claim 1 whensaid program is implemented in a computer program for executing on acomputer or a network device.
 10. Computer program for providing profiledata, comprising program code section for carrying out the operations ofclaim 1 when said program is run on a computer or a network device. 11.Computer program product for providing profile data, wherein saidcomputer program product comprises program code sections stored on acomputer readable medium for carrying out the method of claim 1 whensaid program product is run on a computer or network device.
 12. Networkdevice for providing profile data, said network device (200, 300)comprising a communication interface (231, 330, 331) for receiving arequest and a cookie from a requesting device (100) and for transmittinga response and a response cookie to said requesting device (100), asession manager (210, 310) for providing profile data, wherein saidsession manager comprises a cache (211, 311) for caching said profiledata and is adapted for retrieving said profile data from said cache(211, 311) in accordance with information comprised in said cookie; andfor generating said response cookie comprising session information and aserving component (220, 320) for generating said response based on saidrequest, wherein said serving component (220, 320) is adapted to takesaid profile data into account.
 13. Network device for providing profiledata, said network device (200, 300) comprising a communicationinterface (231, 330, 331) for receiving a request from a requestingdevice (100) and for transmitting a response to said requesting device(100), a session manager (210, 310) for providing profile data, whereinsaid session manager comprises a cache (211, 311) for caching saidprofile data and is adapted for retrieving said profile data from saidcache (211, 311) in accordance with information comprised in a uniformresource locator (URL) of said request and a serving component (220,320) for generating said response based on said request and forprocessing uniform resource locators (URLs) comprised in said responseby including therein information for retrieving said profile data fromsaid cache (211, 311), wherein said serving component (220, 320) isadapted to take said profile data into account.
 14. Network deviceaccording to claim 12, wherein said network device (200, 300) is aserver network device (200).
 15. Network device according to claim 12,said network device (200, 300) further comprising: a communicationinterface (231, 330, 331) for transmitting a server request to a servernetwork device (201) and receiving a server response from said servernetwork device (201) and a serving component (220, 320) for generating aserver request and generating said response additionally based on saidserver response.
 16. Network device according to claim 12, wherein saidnetwork device (200, 300) is a proxy network device (300) or a gatewaynetwork device (300).
 17. System for providing profile data, comprisinga requesting device (100) and a network device (200) according to claim14.
 18. System for providing profile data, comprising a requestingdevice (100), an intermediate network device (300) according to claim 16and a server (201), wherein said requesting device (100) is adapted tocommunicate via said intermediate network device (300) with said server(201).
 19. Method according to claim 2, wherein said profile data areavailable for being retrieved for a certain period of time.
 20. Methodaccording to claim 19, wherein said period of time starts with theinitial receiving of said profile data.
 21. Method according to claim20, wherein said period of time is terminated with the removal of saidprofile data.
 22. Method according to claim 2, wherein said step ofgenerating a response further comprises the steps of: generating (S1.27,S1.16, S5.28, S5.57) a server request based on the client request,transmitting (S1.28, S1.17, S5.29, S5.58) said server request, receiving(S1.29, S1.18, S5.30, S5.59) a server response in accordance with saidserver request and generating (S1.24, S1.13, S5.24, S5.53) a responsebased on said server response.
 23. Computer program for providingprofile data, wherein said computer program is stored on a computerreadable medium for carrying out the method of claim
 2. 24. Networkdevice according to claim 13, wherein said method device is a servernetwork device (200).
 25. Network device according to claim 13, saidnetwork device (200, 300) further comprising a communication interface(231, 330, 331) for transmitting a server request to a server networkdevice (201) and receiving, a server response from said server networkdevice (201) and a serving component (220, 320) for generating a serverrequest and generating said response additionally based on said serverresponse.
 26. Network device according to claim 13, wherein said networkdevice (200, 300) is a proxy network device (300) or a gateway networkdevice (300).
 27. System for providing profile data, comprising arequesting device (100) and a network device (200) according to claim25.
 28. System for providing profile data, comprising a requestingdevice (100), an intermediate network device (300) according to claim 26and a server (201), wherein said requesting device (100) is adapted tocommunicate via said intermediate network device (300) with said server(201).